Designing and fabricating electronic systems typically involves many steps, known as a design flow. The particular steps of a design flow often are dependent upon the type of electronic system being designed, its complexity, the design team, and the fabricator or foundry that will manufacture the electronic system. The design flow typically starts with a specification for a new electronic system, which can be transformed into a logical design. The logical design can model the electronic system at a register transfer level (RTL), which is usually coded in a Hardware Design Language (HDL), such as System Verilog, Very high speed integrated circuit Hardware Design Language (VHDL), System C, or the like. The logical design of the electronic system can be analyzed to confirm that it will accurately perform the functions desired for the electronic system. This analysis is sometimes referred to as “functional verification.”
Functional verification can begin with a circuit design that can be simulated by a design verification tool. The design verification tool utilizing a test bench can generate test stimulus that, when input to the simulated circuit design, can allow the design verification tool to analyze the functionality of the circuit design. The design verification tool can quantify how well a test bench came to covering or adequately exercising the simulated circuit design, for example, with various coverage types. For example, the design verification tool can use statement coverage to quantify whether each executable statement or line of code in the circuit design was executed in response to the test bench. The design verification tool can use decision coverage to quantify whether each coded decision path was utilized in response to the test bench. The design verification tool can use condition coverage to quantify whether all outcomes of a condition, for example, both true and false, were realized in response to the test bench. The design verification tool can use expression coverage to quantify whether expressions in the code of the circuit design, such as Boolean logic structures, were adequately exercised or functionally verified in response to the test bench. The design verification tool can, of course, incorporate many different coverage types, other than those discussed above.
The design verification tool can select one or more of the coverage types to monitor or collect during the simulation of the circuit design, which, in some cases, can be in response to input from a user interface. For each of the selected coverage types, the design verification tool can generate coverage bins that can record occurrences of corresponding coverage events, oftentimes by incrementing counters, during the simulation of the circuit design. For example, when statement coverage is selected, the design verification tool can generate a different coverage bin for each line of code in the circuit design. When a line of code is executed during the simulation of the circuit design, the coverage bin for that line of code can record the fact that the line of code was executed. For other coverage types, such as branch coverage, coverage events can correspond to execution of lines of code along with a presence of conditions in those lines of code.
The design verification tool, after the circuit design simulation has been completed, can gather the records associated with the coverage bins, which can be output to a storage system, such as memory system implementing a Unified Coverage Database (UCDB) or other coverage database format. The design verification tool, or other tool accessing the records in the storage system, can generate one or more coverage metrics. For example, when a statement coverage type was selected to be collected during circuit design simulation, the design verification tool can generate a statement coverage metric from the coverage bin records to quantify whether each executable statement or line of code in the circuit design was executed in response to the test stimulus generated by the test bench during circuit design simulation.
While the existing technique to collect coverage events during circuit design simulation is effective, it is often resource intensive due to all of the counters utilized by the design verification tool to record the presence of the coverage events. This utilization of resources often causes slow processing throughput, leading to longer simulation times. Furthermore, with the recent increased utilization of hardware emulators for functional verification, collection and analysis of test bench coverage during circuit design emulation is also desirable. Unfortunately, the addition of counters, and possibly associated logic, to support coverage bins is impractical given their associated utilization of the available hardware capacity.